Search
System 6 MPU Repair Log
When I got it, it was a clean board that worked a few months ago. Game stopped booting, so owner had rom and 5101 sockets replaced. Repairer says board booted on bench (LEDs turned off), but when installed in game it still didn't reach attract mode.
- I replaced the (still original) CPU and RAM (IC13 only) sockets, but that made no difference
- Installed Leon's test rom (flashes LEDs without using RAM, etc), but it didn't boot either
- Tried Andre's test rom (tests all chips without using RAM, etc), also didn't boot.
- Checked all the inputs of the ROM and PIA chips with logic probe, none were stuck.
- Replaced data line buffers (IC9+10) with jumpers in case they were a problem, but no difference.
- Found out Andre's test rom also strobes A15 line along with LEDs (in case the PIA outputs or LED chip are broken), so I checked that but it also wasn't working. At this point I reason that the problem must be between the CPU and ROM (both known good).
- Although all the address and data lines are strobing, it's still not working, so one must be strobing wrong somehow.
- I write up a quick test rom comprising nothing but infinite loops, reasoning that this will keep the program counter (and thus the address lines since no other accesses are happening) constant. Installed in a known good board, it works as expected. Reading off the address lines one by one reports the address $7800, which is the first byte of the rom.
- When installed in the problem board, A9-11 are low (as expected) but every line below them is strobing. I can't really explain this, why would the CPU be jumping all through a 512 byte subset of memory?
- I Remove the remaining RAM (IC16) and PIA, but nothing changes
- Since the data on the data lines should now be predictable (just reading the entry address, and then that address itself repeatedly), I reason that I should be able to pick it up with a logic analyzer. With mine hooked up to the 8 data lines, I record them at 24MHz (for overkill), and examine them, but I don't see any of that data. # - What I do note though is that at the beginning of the boot, D6 seems to wobble a bit while the rest don't. I don't know if that wobble is normal, but the one reliable thing about any pinball related troubleshooting, I've found, is that if there's 8 of a thing they tend to act the same, so I suspect something is up with the D6 line
- I take out the CPU and rom, meaning that, per my look over the schematics, nothing should be attached to any of the data lines now (and thus they should all be floating), but when I apply power, I still read a signal on D6.
- Something must be shorted somewhere, so I begin checking the resistance between D6 and every other signal on the board, eventually finding that it has continuity to A6. All that's left now is to actually find it
- I begin at the source of D6 (IC9), and visually follow the trace all around the board, looking for any potential problems, but am unable to find any. Usually a short is between two adjacent pads of a chip, but looking at the various chips, none have A6 and D6 near each other. What I do realize though, is that the RAM chips have them directly across from each other. The chips are too wide to have a short that way, but the way these boards are routed with both chips next to each other, they squeezed the signals from the left side of the chip between the right side pads to reach the next chip over, which means the trace gets awfully close to the pads. To make matters worse, due to their cheap board manufacturing process, instead of masking off individual pads for soldering, they just did the whole strip of pads, which includes the traces running between the pads.
- Although I'm unable to see a problem, this area seems suspect, so I desolder the sockets and confirm my theory: there's a tiny bit of solder bridging the pad of D6 to the A6 trace running next to it.
- After removing the solder, the board boots fine
Custom OS for Williams System 3-6 Pinball Machines
Many older games from the dawn of computer based ('solid state') pinball have some pretty basic rules, and I've often pondered hacking the roms to improve them, but reverse engineering assembly from scratch isn't really my idea of fun so I never really got into it. Driving home one night though, I got to thinking: the hardware for these machines is pretty simple, the schematics are available (and even have memory addresses!), would it really be that hard to just write a brand new rom from scratch? Sure, I didn't know assembly or anything, but it couldn't be that hard!
So I sat down with a copy of the Motorola 6800 reference manual, some data sheets, the schematics, and a copy of PinMAME to debug my code in, found where the entry point/address was, and started coding.
Long story short, it actually was pretty easy! The williams hardware was designed for simplicity from a programming standpoint (though that ended up making the boards overly complicated and unreliable), all the I/O was easy to work with and within a few days I had simple drivers written for all the different peripherals and a basic 'OS' for a game that could control lights, display scores, and jump into a callback table when a switch was hit by the ball.
Programming a game itself using this would prove a bit more complicated of course, due mostly to timing/threading issues (of course, I just had to write a custom threading system for this 1MHz processor), but nothing extreme. A few months later, and I had a brand new rom for my Hot Tip, with many fancy new features which I showed off in a video here
I didn't document the whole process very much, but if you'd like to know more, or would like to try to write your own new game rom using this as a basis, drop me a line!
The full source code and roms are available at http://github.com/zacaj/williams-sys-3-6